In the prior art, many programs used the device of a "command line." For example, the AIX (.TM., International Business Machines, Corp.) operating system provides the user with a prompt indicating that the AIX program is expecting user input. This prompt is considered a command line from which the user can submit a command to be processed by the AIX program.
Another example of a program that has a command line is text or word-processing programs which would use this device to distinguish between the entering of text and the entering of a command. In a typical implementation, a user at a keyboard would enter text through a keyboard. An example of a screen display of a text processing program of this type is shown in FIG. 1. As can be seen from FIG. 1, the text would be displayed in a working area (1) which usually comprised the majority of the display area. If the user wished to enter a command, that is, wished to have the word processing program execute a function, the operator would direct the cursor displayed on the display screen into a command line area (5). When the cursor entered the command line area, any characters typed at the keyboard would be interpreted by the word processing program as a command, rather than as text, and would respond by performing the indicated command function. In the prior art, the command line was normally a stationary area located at either the bottom of the display screen (as in FIG. 1) or at the top of the display screen.
While this implementation enabled a program to successfully distinguish between text and commands, its primary drawback was that it was not user friendly. Prior art recognized this problem and tried to ameliorate the situation. For example, U.S. Pat. No. 4,783,759, Borgendale et al., discloses a floating command line. This attempted to solve the problem of requiring the user to move the cursor to one or the other of the extremes of the screen. Borgendale did not address, however, the more basic problems of a command line implementation: first, that a user had to remember the commands, and second, that the user had to type the command correctly. Attempts were made to solve the user's memory problems: some programs assigned certain commands to program function keys and provided cardboard or plastic templates to prompt the user. The drawback to this approach was that, if more than 12 commands needed to be identified, awkward keystrokes were required, ex. alt/pf1 and the templates (which had to cover 36 variations--12 program function keys combined with the ALT, SHIFT, and CONTROL KEYS) became hard to read.
As the use of the personal computer (PC) spread, user friendliness became a critical factor in the commercial success of programs. PC users would typically acquire a number of programs, each with a specific purpose. For example, a typical user might have a spreadsheet such as Lotus-1-2-3 (.TM., Lotus Development Corp.), a word processor such as WordPerfect (.TM., WordPerfect Corp.), and a graphics program. Since each of the programs was specialized, it was not unusual for a program to be used only sporadically, with days, weeks or even months lapsing between each use. In such an environment, the drawbacks of command-line driven applications became more critical: trying to remember different commands for each different program after a hiatus was an annoyance; typing the command (with its potentially unique spelling) correctly could be a major problem.
The increasing sophistication of the graphical capabilities of the PC displays offered one way of solving these problems. Using graphical user interface (GUI) techniques, programmers were able to develop alternatives to command lines. For example, using GUI, a set of "buttons" or target areas would be displayed on the screen. The user could select one of the buttons by using the mouse to move the mouse pointer over the button and then pressing a mouse button. The action of selecting the button indicates to the application program that a specific action is desired--namely, a command correlated with the button. Since the user need only move the mouse, the problem of mis-typing is eliminated. Since the buttons on the screen could be varied to display only those applicable at a given point in a program execution, the busy template problem is avoided. Finally, by using a hierarchy of menus of buttons, an unlimited number of buttons (a.k.a. commands) could be provided to the user.
GUI techniques were a boon to programmers who were writing new programs. There remained, however, the problem of a sizable body of pre-existing programs. Typically, great expense is required to attach a Graphical User Interface to an existing application. Usually, the existing application is re-written and as a result, must be re-tested.
Further, coexistence of GUI programs and command driven programs caused certain difficulties. Not only did the user friendliness of GUI programs magnify the user-unfriendliness of command driven program by their contrast, the users were now faced with two different "standards" of program implementation. In an environment where differences between panels were considered a drawback (refer U.S. Pat. No. 5,179,657, Dyktal, et al.), the difference between GUI and the command line was a major problem. It became clear that to protect the investment base of pre-existing programs, an economic way of converting them to GUI presentation was required.